A. Field of the Invention
The present invention relates to electronic mail systems.
B. Description of the Related Art
E-mail, in its current state, is in dire need of a revisiting. The existing design and architecture allows for virus attacks, “spam” abuse and major security concerns. According to Computer Associates, 90% of viruses are passed through e-mail, which makes users more cautious than ever about what e-mail they open. 51% of corporations have had a virus disaster and six major viruses over the last five years have resulted in $20B in estimated global costs. In 2005, more than 200 viruses actively spread on the Internet resulting in approximately 0.65% of all e-mail messages carrying a virus.
According to the Meta Group, 75% of all corporate knowledge is communicated via e-mail (2005). The number of corporate e-mail messages sent daily worldwide is expected to double by 2006, from 31 billion messages to 60 billion. The cost of unsolicited e-mail to US and European businesses last year amounted to $11.4B. For ISPs the cost was $500M. In addition to the financial cost, this ever-growing problem of unsolicited e-mail has created security, liability, and productivity issues for organizations.
The rapid growth of e-mail has resulted in an increasing awareness of the security threats and the need for solutions to safeguard corporate networks and data. In an ever-changing landscape of products, providers and services in this growing market, millions of dollars are spent every year trying to strengthen the infrastructure of corporations in order to protect its data from spam and viruses.
Existing multi-layered protection methods typically consist of adding extra scanning processes, traps and quarantine areas, all within the network of the corporation, to reduce spam and virus intrusions. Current trends suggest that these multi-layer methods cannot stop the increase in spam e-mail and viruses. Reinforcing the infrastructure is an ad hoc solution; by the time anti-spam and anti-virus protection systems intercept the message, it already resides inside the corporation's firewall. In some cases it might not even be necessary to open the malicious e-mail; just receiving it may be enough to create damage (e.g., in the case of self-executable viruses). From a legal perspective, the digitization of documents has created a large problem in being able to track who has what copy and which was the original version. New trends surrounding archiving and tracking e-mail communications are covered daily by the press because of the following pressure points which traditional e-mail does not cover:
Compliance: The Sarbanes-Oxley (US) compliance for the Securities and Exchange Commission and the Health Insurance Portability and Accountability Act (US) both require that valid records of electronic communication between employees and clients be kept. With traditional e-mail, guaranteed tracking and auditability cannot be reliably achieved, and thus compliance cannot reliably be achieved in any easy manner.
Public disclosure of confidential material: Traditional e-mail has no way of tracking or recording unauthorized message forwarding or interception. These pitfalls make e-mail an unattractive solution for the transference of sensitive materials.
Archiving: Archivists commonly require the original document not to be changed or tampered with.
Records Management: Requirements often demand that all copies of the original document be keep in an archive.
Existing e-mail network infrastructures and protocols (hereinafter collectively “e-mail1”) have only limited tracking capabilities. Messages typically cannot be tracked between different e-mail servers and recipients; incomplete transactions due to different software configurations create non-guaranteed tracking records. Companies offering e-mail1 tracking systems typically either require users to change e-mail addresses so that messages are routed through the same server, or worse, require HTML and JavaScript embedded into each message in order to track executables (code) rather than the actual e-mail message.
Additionally, e-mail encryption methods, such as PKI, are not widely used today despite their existence for more than 10 years. This is partly because such technologies are not easy to use. For example, PKI requires each user (sender and recipients) to manually set-up their own certificate or private key, and then manually exchange this key with other users. Many users do not know how to manage their key files, creating security loopholes in the process.
Limitations of E-Mail1 Message Control and Metadata Functionality
Existing e-mail systems have several inherent limitations in the areas of message control and metadata functionality. Due to the architecture that e-mail1 is based upon, many potentially useful features are impossible or only possible to partially implement.
For example, using Microsoft's Outlook e-mail client, users have the option to ‘recall’ a message. This feature potentially ‘un-sends’ an e-mail sent in haste, or one that was sent to the incorrect recipient. However, Outlook's recall functionality typically can only work within an internal domain—a large company's e-mail network, for instance. Even then, different configuration settings on recipient computers can thwart attempts to recall messages. Because many of the people a user communicates with on a regular basis are not a part of the user's internal domain, this feature is significantly less useful than it could be.
As another example, many e-mail clients incorporate a ‘voting system’, but these tend to be available only for the simple task of providing feedback to the initial sender. These voting systems do not generally allow for more complex peer-to-peer or user-driven ratings in which feedback is available to persons other than the original sender. Further, such systems are generally not extensible in that they do not allow for easy introduction of new types of e-mail metadata functionality.
E-Mail1 Architecture and Backward Compatibility
Although the existing e-mail1 architecture is both outdated and ineffective, e-mail1 is widely accepted as the worldwide standard for online communication. There is an enormous amount of infrastructure, both hardware and software systems, devoted to maintaining and propagating e-mail1 messages. Because of the universally massive investment in e-mail1 infrastructure, it is desirable that any solution to the multitude of problems found in e-mail1 be backwards compatible, and that it not disrupt the current flow of e-mail1 communication.